home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15467 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: nova.nuc.umr.edu!not-for-mail
  2. From: sdrumm@nova.nuc.umr.edu (Scott Walter Drumm)
  3. Newsgroups: comp.lang.c++
  4. Subject: Numerical Class Ideas
  5. Date: 3 Apr 1996 16:29:29 -0600
  6. Organization: UMR Nuclear Engineering.
  7. Message-ID: <4juu49$l7u@nova.nuc.umr.edu>
  8. NNTP-Posting-Host: nova.nuc.umr.edu
  9. X-Newsreader: TIN [version 1.2 PL2]
  10.  
  11.  
  12. I was wondering if any of you could give me some advice in constructing
  13. a class library for numerical analysis routines.  I have all the
  14. necessary algorithms, but am not quite what the best way is to structure
  15. the class hierarchy.
  16.  
  17. Currently I have a primeval base class containing an error-handler and
  18. other associated functions that are inherited by all other classes.
  19. From that point I can see three basic options:
  20.  
  21.   1.  Declare each routine as a new class descended from the primeval
  22.       base class.  Thus, there would be separate classes for Bisection,
  23.       Newton-Raphson, Ridder's Method, etc. (using root-finding algorithms
  24.       as an example).  This results in a two-level inheritance tree, and
  25.       is the most straightforward implementation but it doesn't take much
  26.       advantage of C++'s capabilities.  For this approach, the only real
  27.       gain is in avoiding a global declaration of the error-handler.
  28.  
  29.   2.  Create intermediary classes off of the base class for each group
  30.       of similar algorithms.  Thus, there would be a Root_Find class
  31.       from which the above algorithms would be descended from.  This
  32.       would allow me to group the initialization and output routines for
  33.       each algorithm together; however, most of the routines are of the
  34.       simple float f(..) variety, and don't have much in the way of
  35.       initialization/output code, so I don't know how much I'd gain.
  36.  
  37.   3.  Forget a class implementation, code them all as separate functions
  38.       and stuff them into a .c file.  ;)
  39.  
  40. I suppose the crux of the matter is this: Is it worth it to create
  41. categorical classes (which cannot be used by themselves) merely to force
  42. basically unrelated functions together in a multi-level class hierarchy?
  43.  
  44. Brief examples, bits of wisdom, slaps upside the head, etc. would be
  45. appreciated.  Thanx.
  46.  
  47.  
  48.  
  49. /----------------------------\/--------------------------------------------\
  50. |                            |               OS/2 v3.0 - Warp              |
  51. |     ------------------     |       Isn't it time to expect more from     |
  52. | sdrumm@albert.nuc.umr.edu  |            your operating system?           |
  53. \----------------------------/\--------------------------------------------/
  54.  
  55. GE(Nuclear) d? H-- s !g p?+ au+ a23 w+++ !v C++++ UB+ P? L 3 E-- N++ K- 
  56. W--- M-- V-- po+ Y++ t++ 5++ !j R++ G''' tv b++ D++ B--- e-- -u h+ f !r n+ !y+
  57.  
  58.  
  59. -----BEGIN PGP PUBLIC KEY BLOCK-----
  60. Version: 2.6
  61.  
  62. mQCNAy77IHoAAAEEALYk690QdoGgkqB7ocVmK3txmAns9e1G5N4Osm+G7sg+UGeq
  63. DZsmkG1tPcFrfYZJG5EnGhrLo7UnAktaajWCD8rwAjAiwNWLcMnpG/rRFXOwPSfR
  64. 0U5/ovqtX7P8pxn3Z8Z0yB+4l1J1QU4EOtE5oRE6zqV4wCI+mXvsBan6w9vZAAUR
  65. tCpTY290dCBXLiBEcnVtbSA8c2RydW1tQGFsYmVydC5udWMudW1yLmVkdT4=
  66. =g0jL
  67. -----END PGP PUBLIC KEY BLOCK-----
  68.  
  69.